1. Field of the Invention
The present invention relates to a procedure calling method and more particularly, to a procedure calling method that performs procedure calling in the object-oriented technology.
2. Description of the Prior Art
A procedure calling method which has been most widely accepted in the object-oriented technology is that which uses a paired information table for procedure names and the addresses of procedures represented by the names. The information table is termed a "procedure assignment table". A typical example of the procedures is a function.
An example of the conventional procedure calling methods of this sort is shown in FIG. 1. As shown in FIG. 1, this method contains a procedure name acquisition step S101, a procedure assignment table reading step S102, a procedure address judging step S103, a procedure address acquisition step S104, a procedure execution step S105, and an execution error output step S106.
With the conventional procedure calling method of FIG. 1, procedure assignment tables, each of which contains sets of a name and address of a procedure, are previously prepared by a translation system (such as a compiler) of the source program. An example of the procedure assignment table is shown in FIG. 2, in which the reference numeral 81 represents a procedure assignment table of the class A1, and the reference numeral 82 represents a procedure assignment table of the class A.
If a procedure name is specified as the key in the step S101, a corresponding procedure address listed in the corresponding procedure assignment table (for example, the table 81 or 82 in FIG. 2) can be obtained through the seeps S102 to S104. Therefore, if a procedure assignment table is prepared for each class (each of the classes A and A1 in FIG. 2), different processes can we executed with the same procedure name in the tables of the different classes.
When a plurality of procedure assignment tables are provided for a single procedure name, the pertinent procedure assignment table may be determined in executing the program by the execution code prepared by the translation system such as a compiler.
For example, when a derived class is used by defining it from the base class which is equivalent to the root of the inherited hierarchy tree, each of the procedure assignment tables, the number of which is the same as that of the derived classes, is provided with an entry of the same procedure name as that of the base class. In this case, the source program has a statement to which a certain procedure P for an object variable V is applied. If the procedure P is redefined in the derived class, the procedure assignment table is found out and read on the basis of the class information including the class name of the object to be substituted into the object variable V on execution (see step S102 in FIG. 1). Further, a code to determine the execution code for the correct procedure P (see steps S104 and S105 in FIG. 1) is generated by the compiler.
With the conventional procedure calling method as stated above, in which the procedure assignment table is determined for each class name, the procedure assignment table cannot be changed over with an application program. As a result, a problem that it is difficult for an appropriate procedure to be able to be mutually called safely between separately-prepared application programs occurs.
For example, as shown in FIG. 2, it is supposed that an application program contains the definition of the base class A, and another application program contains the definition of the base class A and the definition of a derived class A1 thaw uses the definition of the class A. It is also supposed that the address of the execution code corresponding to a procedure name "func i" of the derived class A1 is set as the address of the execution code for a procedure name "func i" of the base class A, i.e., "$A::func i", as show-n in the procedure assignment tables 81 and 82 of the classes A1 and A.
If the base class A is updated independently of the derived class A1, the execution code stored in the address "$A::func i" in the procedure assignment table 82 of the base class A may be replaced. Therefore, it cannot be assured that the procedure "func i" of the derived class A1 always provides the operation or behavior that was expected by the definition of the class A1.
To avoid such a problem, the Microsoft Component Object Model adopts a procedure calling method as shown in FIG. 3.
For this procedure calling method of FIG. 3, the address of the function corresponding to the procedure for an object in an application program is not determined by the compiler; but determined through the "QueryInterface" procedures in the special function tables IUnKnown 911 and 921, to which all function tables must be related. These function tables are equivalent to the above-described procedure assignment tables.
With the procedure calling method shown in FIG. 3, the programmer provides an application program so that the "Interface" is defined as a group of functions or procedures in the function table or procedure assignment table, and the reference (i.e., pointer) to the "Interface" corresponds to the return value of the "QueryInterFace" procedure.
In the example in FIG. 3, to allow the function "func i" stored in the procedure assignment table 912 of the derived class A1 to use the execution code for the function, "func i" stored in the procedure assignment table 922 of the base class A, the programmer must provide the "QueryInterface" procedure in the "Iunknown" table 911 related to the class A1 so that the "interface" obtained by the "QueryInterFace" procedure in the "Iunknown" table 921 related to the class A is returned. In other words, in providing the "QueryInterface" procedure for a function listed in the "Iunknown" function table: the programmer must make an explicit statement so that the code to be reused is related.
With the conventional procedure calling method of FIG. 3, since such a contrivance as checking the versions of the class A in FIG. 3 is allowed in making the relationship of the code to be reused, the programmer is able to avoid the above problem in the conventional procedure calling method as shown in FIG. 2.
However, for a function that is certain to be reusable, the programmer must retrieve the code for making the relationship of the code to be reused, and explicitly provide or state it. This causes a problem of an increased load imposed on the programmer.
In addition, because the "Interface" is a group of functions, even when an execution code of the base class (the class A in FIG. 3) is to be reused for only a single function in the "Interface" group, the entire "Interface" must be reused for only the single function, or the same code as that of the base class must be newly stated for its reuse. This causes another problem that efficient reuse of the code is difficult.